As the world becomes more globalized, the need to communicate with people in different countries using different languages increases. Also, given today's society, and the difficulty of speaking in different languages with people multiple time zones away, much of today's communication is done in writing. While people can easily handwrite characters in different languages, it is more difficult to integrate the many different characters used in writing systems throughout the world into a uniform system that can be used to type the characters on a computer.
Many attempts have been made to encode characters used in writing systems throughout the world. Over the years, a standard known as Unicode has become the leading industry standard for encoding these writing systems. Unicode works by encoding characters within a writing system into hexadecimal format, which allows for a character to be consistently represented by a unique hexadecimal value. However, since not all of the writing systems were originally encoded in a Unicode format, it becomes necessary at times to map one or more characters from a non-Unicode supporting format to a Unicode supporting format.
Currently, non-Unicode supporting formats have been transformed into Unicode supporting formats using parsers. A parser is a program, or part of a program, which obtains a string (e.g., a block of text) and identifies the structure of the string based on a set of rules. Once the structure is obtained, a new rule can be applied to the string to change the string. For example, a parser could be used to locate data types that are defined as Single (i.e., those data types storing up to four bytes of data) and change them to a Double (i.e., a data type capable of storing up to eight bytes of data). While parsers may be used to change strings into a Unicode supporting format, it becomes problematic to use parsers when entire serially linked type definition files, or applications, need to be converted from non-Unicode supporting formats to Unicode supporting formats. The problem lies in the fact that additional manual activities of code change, or configuration setting changes such as using parsers and change of type definition properties, e.g., single byte to double byte, need to be implemented manually for each applicable type definition. For example, one type definition file may be used to define thousands of data types and an application may be built around multiple type definition files.
More specifically, a serially linked application is when a first application outputs data and a second application directly picks up the output of the first application. Examples of serially linked applications include many implementations of enterprise application integration (EAI) software. The problem with using a parser on serially linked applications is that all of the applicable data structures would have to be changed in middleware to avoid complications from transferring an output from a first application having already been converted from a non-Unicode supporting format to a serially linked second application that has not yet been converted from a non-Unicode supporting format. To make a parser work in this kind of situation would require substantial changes to a system's architecture, which is costly and time consuming. Similarly, manual changes, or replacing an entire system, would also be costly and time consuming.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.